We shouldn't need cosa for this.

So here's how I think this would go roughly:

• Based on some trigger (e.g. polling new RPMs out of COPR, or there's a new quay.io/fedora/fedora-coreos:stable image published), start this job
• Do a podman build of an image that does FROM: quay.io/fedora/fedora-coreos:stable, and e.g. removes moby, adds the podman RPMs, adds subscription manager, etc...
• Run osbuild to convert the container image into disk images using the same manifests we use (these are currently hosted e.g. here and here, but I think the goal is to move them out). This requires running on a system with full root privileges. For aarch64, GHA was planning to add runners but it's not clear if that has happened yet. Alternatively, you can have a self-hosted runner on e.g. AWS. Nested virt shouldn't be required AIUI since osbuild uses loopbacks instead.
• Bundle up the disk images into container images and push to the registry

For the triggering, probably the simplest is polling and comparing the latest versions of the RPMs and base FCOS image against the latest pushed podman machine images (e.g. you can store the versioning in labels).

/cc @dustymabe @baude

I wrote this today for @baude: https://github.com/dustymabe/build-podman-machine-os-disks/blob/56ecb7dc0437c1abcbaf6d6a7a806d96edcdab6f/build-podman-machine-os-disks.sh#L4-L25

so basically step 3 turns into "run this script" in an environment that can run OSBuild (i.e. run as root, selinux permissive, some osbuild RPMs installed).

We shouldn't need cosa for this.

Ack

• Based on some trigger (e.g. polling new RPMs out of COPR, or there's a new quay.io/fedora/fedora-coreos:stable image published), start this job
• Do a podman build of an image that does FROM: quay.io/fedora/fedora-coreos:stable, and e.g. removes moby, adds the podman RPMs, adds subscription manager, etc...

These two steps are pretty much happening already using https://github.com/containers/podman/blob/main/contrib/podman-next/fcos-podmanimage/Containerfile . This was taken from https://github.com/coreos/layering-examples/tree/main/podman-next .

subscription-manager addition isn't being done yet, I'll defer to @baude on that.

The container images built are pushed to https://quay.io/repository/podman/fcos?tab=tags .

• Run osbuild to convert the container image into disk images using the same manifests we use (these are currently hosted e.g. here and here, but I think the goal is to move them out). This requires running on a system with full root privileges. For aarch64, GHA was planning to add runners but it's not clear if that has happened yet. Alternatively, you can have a self-hosted runner on e.g. AWS. Nested virt shouldn't be required AIUI since osbuild uses loopbacks instead.

• Bundle up the disk images into container images and push to the registry

Ack, thanks. I'll look into these two.

For the triggering, probably the simplest is polling and comparing the latest versions of the RPMs and base FCOS image against the latest pushed podman machine images (e.g. you can store the versioning in labels).

Ack. The trigger for the existing action right now is a commit to the main branch of podman followed by a successful rpm build at the podman-next COPR. This is done using https://github.com/packit/wait-for-copr.git . So far, we haven't been checking for image updates at quay.io/fedora/fedora-coreos:stable though IIUC that's part of upcoming work.